Intent to change: `click`, `auxclick`and `contextmenu` event target is the preceding `pointerup` event target if and only if the pointer is captured when the `pointerup` is dispatched

Summary: Pointer Events defines `click`, `auxclick`, `contextmenu` event target should be the same target as its source event if and only if the source event is a `pointerdown` or a `pointerup` and the pointer is captured at dispatching the source event (the source event of `contextmenu` may be `pointerdown`, which depends on when the OS dispatches the native `contextmenu`). Currently, we conform to the case when the source event is `pointerup`.

I.e., we change the behavior when:

• pressing and releasing a button of mouse and the web app explicitly capture the mouse
• single tapping and the web app explicitly capture the touch
• single tapping and the web app does not release the implicit capture of the touch  (the traditional behavior for a tap)

So, we don't change the behavior when:

• pressing and releasing a button of mouse and the web app does not capture the mouse (the traditional behavior for a mouse button press)
• single tapping and the web app explicitly release the capture of the touch
• pressing the secondary button of mouse and `contextmenu` is dispatched

This means that we don't change the traditional behavior of the mouse click.

Finally, we need to fix the last case, i.e., `contentmenu` dispatched without `pointerup` in a follow up bug.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1885232

Specification: https://w3c.github.io/pointerevents/#event-dispatch (the last paragraph of the step #3)

Preferences: `dom.w3c_pointer_events.dispatch_click_on_pointer_capturing_element`

web-platform-tests: https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&q=pointerevent_click_during_capture

-- 
Masayuki Nakano <masa...@d-toybox.com>
Working on DOM, Events, editor and IME handling for Gecko

Unfortunately, the new standardized behavior caused a web-compat issue in Phabricator if and only if you use a touch screen. One of the reasons is, Chrome has not changed the behavior for the `click` caused by the compatibility mouse events of a touch. We're still not sure whether it's intentionally not changed or just a bug. Anyway, we considered that we should stop taking the risk caused by the incompatible behavior from Chrome at least for now.

So, the standardized behavior will be applied only for non-touch inputs (currently, it means only for mouse inputs).